System and method for communicating between software applications, particularly mes (manufacturing execution system) applications

ABSTRACT

Applications to be connected, particularly MES (manufacturing execution system) applications, as well as the communications mechanisms are depicted in the object model of the framework (IF; IF meaning industrial framework) by using wrappers and/or adapters and, as a result, can be manipulated in a uniformly homogenous manner in the framework. The invention is advantageous in that the very heterogeneous structures of the applications are depicted on a common model and can be comfortably and easily used by a user by means of generic mechanisms. That is to say that the effort of programming is eliminated and, as a result, this communication can be easily projected by establishing a so-called connection.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is the US National Stage of International ApplicationNo. PCT/DE02/04376, filed Nov. 28, 2002 and claims the benefit thereof.The International Application claims the benefits of German applicationNo. 10161064.5 filed Dec. 12, 2001, both of the applications areincorporated by reference herein in their entirety.

FIELD OF INVENTION

The invention relates to a system for communicating between softwareapplications, particularly MES applications, with at least one means ofcommunication, at least one central processing unit for storing thesoftware applications and at least one framework program coupling thesoftware applications together.

The invention also relates to a respective method, a computer program, acomputer program product and also a data processing apparatus.

BACKGROUND OF INVENTION

The employment of what are referred to as Manufacturing ExecutionSystems (MES) for automating production and/or manufacturing sequencesis known from “Software für die Automatisierung—Transparenz über dieAbläufe schaffen”, an article by Dirk Kozian in Elektronik für dieAutomatisierung 11, Nov. 17, 1999. These systems integrate theautomation level (controls) with the ERP systems (ERP: EnterpriseResource Planning) of the enterprise control level. ManufacturingExecution Systems are systems which provide information for optimizingproduction sequences, for example. In the first place, ManufacturingExecution Systems have to supplement the rough planning data of the ERPsystems with plant-specific and up-to-date fine planning data andforward it correspondingly to the lower-placed automation layer; in thesecond place, they have the task of taking production-relatedinformation from the automation level, processing it and reporting it tothe enterprise control level. MES systems therefore perform the task ofvertical integration between the enterprise control level and theautomation level. Typical individual tasks of MES systems compriseEnterprise Asset Management, Maintenance Management, InformationManagement, Scheduling, Dispatching and Trace & Track. These tasks arecarried out by MES components or MES applications in each case.

Due to the software-related and data-related heterogeneity of the MESapplications, however, they can only be integrated into a common systemor project with very great difficulty and the exchange of data betweenthese applications is only possible with some effort.

The integration of software components into a software system by meansof what are referred to as adapters or by means of wrapping (packaging)is known from “Massive Wiederverwendung: Konzepte, Techniken undOrganisation”, an article by Ulrich Lindner in OBJEKTspektrum January1996, pages 10-17. The aim in this respect is to increase thereusability of software components.

U.S. Pat. No. 5,557,798 describes a communication interface betweensoftware applications over which the applications can communicate with ahigh level of performance. The aim in this respect is also to be able todevelop the applications independently of each other in a modularmanner.

U.S. Pat. No. 6,115,646 describes a process automation system based on aheterogeneous distributed software system and an ORB (Object RequestBroker). CORBA (Common Object Request Broker Architecture) is used asthe ORB in this respect. The aim of this invention is to make workflowmanagement services available.

SUMMARY OF INVENTION

The problem addressed by the present invention is to provide a systemand a method for communicating between software applications,particularly MES applications, which allows the easy integration ofheterogeneous applications in particular and the enabling of anefficient exchange of data between them.

According to the invention, the aforesaid problem is solved for a systemby the features of Claim 1. In this respect, the inventors took as theirbasis the finding that interoperability between heterogeneous softwareapplications (e.g. MES applications) is achieved by the use of aframework program (Framework) using standardized interfaces such as OPC(OLE for Process Control), ActiveX, XML (eXtensible Markup Language) orSOAP (Simple Object Access Protocol). This achieves the principle of“any data, any time, anywhere” for a user in an MES project (a projectfor solving a task, e.g. order processing within an MES system). Inother words, a user has access to all data at all times, irrespective ofwhere it is located in the system. Furthermore, all the objects and dataof the applications appear in the framework program in a homogeneous waysince the objects or data of the applications are mapped to the objectmodel (corresponding therefore to a uniform homogenous meta objectmodel) of the framework program. This facilitates the establishment andmanipulation of a communication link between the applications. A usercan project a communication link between applications and does not needto program it laboriously.

A user (e.g. a System Integrator) gains a homogenous view across theoverall system and does not need to have any specific (internal)knowledge of the application programs.

A first advantageous version of the present invention for a systemconsists in the communication link being transparent for a user and/orother systems with respect to the underlying means of communication. Dueto the independence and transparency of the underlying means ofcommunication, e.g. HTTP (Hyper Text Transfer Protocol), COM (ComponentObject Model), DCOM (Distributed Component Object Model) or MSMQ(Microsoft Message Queue), with respect to the projected communicationlink, a user can ignore these means of communication when projecting acommunication link. Therefore, a user does not need to worry about theimplementation details of that means of communication when projecting.Even in the integration or “connection” of the software applications tothe framework program (e.g. by means of wrapping or by means ofadapters), a user can ignore the underlying means of communication anddoes not need to know any implementation details of the means ofcommunication.

A further advantageous version of the present invention for a systemconsists in the mapping to the object model being effected by means ofadapters and/or wrapping. Adapter and wrapper technologies are familiarmechanisms in Information Technology for integrating software componentsinto a system. A wrapper maps the API (Application ProgrammableInterface) of a foreign component (e.g. an MES application of athird-party supplier) into the object model of the framework program.Thus, for example, a method of the API of the foreign component becomesa method of the framework program or an integer data type of the API ofthe foreign component becomes an integer data type of the frameworkprogram, etc. The creation of a wrapper for a component to be integratedcan be automated for COM (Component Object Model) objects. A wrappercorresponds to a bridge. Wrappers can be implemented very quickly.

Adapters are one level of abstraction higher than wrappers. They offer auniform view of coupled applications. An adapter offers functionality tostart up, operate, etc., the component to be coupled. An adaptercorresponds to a “facade” in the language of design patterns.

A further advantageous version of the present invention for a systemconsists in the communication link being set up with a display devicewith input tools and/or via an autonomously operating program. Thisincreases flexibility for the user. A communication link can be set updynamically, i.e. at runtime, for example, by activating a batch. Theautonomously operating program can be defined as a batch and usedseveral times.

A further advantageous version of the present invention for a systemconsists in the communication link being set up between two or moreobjects by connecting the objects, which are shown in different screenareas of the display device, by means of a drag & drop operation withthe aid of the input tools. Given a suitable user interface (e.g. withgraphics support, drag & drop mechanisms, mouse input, voice input,etc.), the projecting becomes convenient and simple for the user.

According to the invention, the aforesaid problem is solved for a methodby the features of Claim 6. This achieves the principle of “any data,any time, anywhere” for a user in an MES project (a project for solvinga task, e.g. order processing within an MES system). In other words, auser has access to all data at all times, irrespective of where it islocated in the system. Furthermore, all the objects and data of theapplications appear in the framework program in a homogeneous way sincethe objects or data of the applications are mapped to the object model(corresponding therefore to a uniform homogeneous meta object model) ofthe framework program. This facilitates the establishment andmanipulation of a communication link between the applications. A usercan project a communication link between applications and does not needto program it laboriously.

A user (e.g. a System Integrator) gains a homogenous view across theoverall system and does not need to have any specific (internal)knowledge of the application programs.

A further advantageous version of the present invention for a methodconsists in the communication link being transparent for a user and/orother systems with respect to the underlying means of communication. Dueto the independence and transparency of the underlying means ofcommunication, e.g. HTTP (Hyper Text Transfer Protocol), COM (ComponentObject Model), DCOM (Distributed Component Object Model) or MSMQ(Microsoft Message Queue), with respect to the projected communicationlink, a user can ignore these means of communication when projecting acommunication link. Therefore, a user does not need to worry about theimplementation details of that means of communication when projecting.Even in the integration or “connection” of the software applications tothe framework program (e.g. by means of wrapping or by means ofadapters), a user can ignore the underlying means of communication anddoes not need to know any implementation details of the means ofcommunication since the means of communication are also mapped to theobject model of the framework program.

A further advantageous version of the present invention for a methodconsists in the mapping to the object model being effected by means ofadapters and/or wrapping. Adapter and wrapper technologies are familiarmechanisms in Information Technology for integrating software componentsinto a system. A wrapper maps the API (Application ProgrammableInterface) of a foreign component (e.g. an MES application of athird-party supplier) into the object model of the framework program.Thus, for example, a method of the API of the foreign component becomesa method of the framework program or an integer data type of the API ofthe foreign component becomes an integer data type of the frameworkprogram, etc. The creation of a wrapper for a component to be integratedcan be automated for COM (Component Object Model) objects. A wrappercorresponds to a bridge. Wrappers can be implemented very quickly.

Adapters are one level of abstraction higher than wrappers. They offer auniform view of coupled applications. An adapter offers functionality tostart up, operate, etc., the component to be coupled. An adaptercorresponds to a “facade” in the language of design patterns.

A further advantageous version of the present invention for a methodconsists in the communication link being set up with a display devicewith input tools and/or via an autonomously operating program. Thisincreases flexibility for the user. A communication link can be set updynamically, i.e. at runtime, for example, by activating a batch. Theautonomously operating program can be defined as a batch and usedseveral times.

A further advantageous version of the present invention for a methodconsists in the communication link being set up between two or moreobjects by connecting the objects, which are shown in different screenareas of the display device, by means of a drag & drop operation withthe aid of the input tools. Given a suitable user interface (e.g. withgraphics support, drag & drop mechanisms, mouse input, voice input,etc.), the projecting becomes convenient and simple for the user.

A further advantageous version of the present invention consists in themethod according to the invention being implemented by means of acomputer program. This makes it possible to carry out any modificationsor adaptations easily.

A further advantageous version of the present invention consists in thecomputer program for the method according to the invention being storedon a data carrier or a computer program product (floppy disk, CD, etc.).This makes the method easy to manipulate with respect to logistics anddistribution.

A further advantageous version of the present invention consists in thecomputer program for the method according to the invention beinginstalled on a data processing apparatus. This increases performance.

BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages and details of the invention arise on the basis ofthe description of advantageous exemplary embodiments which now followsand in connection with the diagrams. Where elements with the samefunctionalities are described in different diagrams, they are labeledwith the same reference symbols.

The diagrams show:

FIG. 1 the “enterprise pyramid” with three control levels, in a generaloutline diagram,

FIG. 2 an exemplary general layout diagram with software and hardwareunits for MES solutions,

FIG. 3 the central position of the framework program coupling thesoftware applications,

FIG. 4 the object structure of a component as a meta object model of theframework program in UML,

FIG. 5 an example of the mapping of an application (WinCC) to acomponent as a meta object model of the framework program,

FIG. 6 a further example of the mapping of an application (SAP) to acomponent as a meta object model of the framework program,

FIG. 7 a communication link between MES applications,

FIG. 8 the object structure of a connection in UML,

FIG. 9 the schematic structure of an adapter and

FIG. 10 screen areas for projecting a connection.

DETAILED DESCRIPTION OF INVENTION

The diagram in FIG. 1 shows the three control levels as they are usuallyto be found in a producing or manufacturing enterprise, in a generaloutline diagram. The pyramid shape expresses the idea that informationis condensed in the upward direction. The topmost level is the ERP(Enterprise Resource Planning) level. The business management and salestasks in an enterprise (e.g. finance, sales, human resources andreporting) are usually carried out on this enterprise control level. Butlogistical tasks spanning production plants (e.g. order management andmaterials management) are also carried out on this level. The system SAPR/3 is an ERP system which is used very frequently on the enterprisecontrol level.

The bottommost level of the pyramid is the automation level (controls).Stored-program controls (SPC) are usually employed on this level inconjunction with visualization and process control systems (PCS). Thedrives, actuators and sensors of the production and/or manufacturingapparatus are in direct connection with the systems on this level.

The connecting element between the ERP level and the automation level isformed by the MES level. The applications of the MES level thereforeprovide vertical integration between the ERP level and the automationlevel.

On the one hand, MES applications have to supplement the rough planningof the ERP systems with production plant-specific fine planning andforward it to the systems of the automation layer; on the other hand, itis the task of the MES applications to take up production-related dataof the automation level, process it and forward it to the ERP level(enterprise control level).

Typical MES applications-comprise, for example, Quality Management (QM),Maintenance Management (MM), Performance Analysis (PA), ProcessManagement, Labor Management and Asset Management. Three dots in eachcase express the idea in FIG. 1 that further elements (applications,systems, etc.) can be located on a level.

As a rule, MES systems or ERP systems contain what is referred to as aruntime system for time-based sequence control of the componentsinvolved (subcomponents, modules, tasks, operating system processes,etc.) and also what is referred to as an engineering system for creatingand editing programs which are provided for execution in the runtimesystem.

The diagram in FIG. 2 shows an exemplary general layout diagram withsoftware and hardware units for MES solutions. The individual MESapplications A1 to A3 are connected via adapters AD1 to AD3 to aframework program (Framework) IF. A user workstation PIW1 is coupled viaa bidirectional information pathway I1 to the framework program IF andcan therefore manage and monitor the MES applications attached to orintegrated into it. The user workstation PIW1 usually consists of adisplay device (monitor, display, etc.), a data processing system (e.g.PC) with a processor and memory facilities and also input units(keyboard, mouse, etc.). The MES applications Al to A3 and also theframework program IF can run on dedicated data processing units orprocessors, but it is also possible for them to run on the dataprocessing unit of the PIW1.

The respective MES applications A1 to A3 are connected via adapters AD1to AD3 to the framework program IF. The adapters are therefore thecoupling blocks between the framework program IF and the applications.Intrinsically heterogeneous applications can therefore also be connectedto each other via the adapters and it is possible, due to theintegration with the framework program IF, to communicate between theapplications and operate the exchange of data. The adapters are softwaremodules which set up connections to various applications. In typicalintegration scenarios, these comprise integrations relating to systemsfrom the MES, ERP, SCADA or controls worlds. An adapter offersfunctionality to start up, operate, etc., a component to be coupled. Anadapter allows access to data and functions of the program orapplication to be coupled, makes certain runtime data available andallows the loading of engineering information from the program orapplication to be coupled. Adapters can differ in terms of theirstructure and scope. Thus, for example, adapters can be permanentlyprogrammed or they can be configured or modeled. They can also differwith respect to the possibilities for access to the application to becoupled; thus, for example, adapters can permit only one data-relatedaccess but it is also possible for adapters to grant access tohigher-value business processes. During start-up, the adapters areloaded together with the stored models and status information. Atruntime, a check is then carried out as to whether and how the differentintegrated applications fit together. It is possible, via avisualization or monitoring component, to interrogate the status of anadapter and represent it (including graphically) on the user workstationPIW1. Adapters give the system and also the user a standardized anduniform view of applications (depending on what level of abstraction ispresent in the adapters).

A further option for integrating software components is to employwrappers. A wrapper maps the API (Application Programmable Interface) ofa foreign component (e.g. an MES application) into the object model ofthe framework program. Thus, for example, a method of the API of theforeign component becomes a method of the framework program or aninteger data type of the API of the foreign component becomes an integerdata type of the framework program.

Alongside MES applications, applications from the enterprise controllevel (Enterprise Resource Planning level) and from the automation level(controls level) can also be integrated via the framework program IF andmonitored or managed via the workstation PIWI (the abbreviation PIWstands for Personalized Industrial Workplace). The framework program IFtherefore forms an integration platform for the entire industrialsector. Different applications from the enterprise control level, theMES level and the automation level can be integrated by the frameworkprogram IF simply and cost-effectively with the aid of adapters and/orwrappers. The framework program IF must therefore be regarded as amiddleware platform and as a manufacturing application integration tool.An end user (e.g. the plant operator) can see the respective status ofthe applications to be monitored via the workstation PIW1 and he canalso access data and methods of the applications and furthermore, he canconnect applications to each other by means of this access.

The framework program IF therefore makes it possible firstly to achievea vertical integration of applications from different enterprise levelsand secondly the framework program IF enables a horizontal integrationof applications on the MES level.

The workstation PIW1 represents “One Window to the World”for an end userat the front end of MES applications or other applications from theenterprise. In other words, the workstation enables integrating accessto different, including heterogeneous, applications in the enterprisevia a common, uniform user interface. The end user of the workstationPIW1 can therefore monitor and manage all integrated MES or otherapplications from this one workstation. This workstation can beconnected to the applications via the Internet, Intranet, LAN (LocalArea Network) or other conceivable connections. It is also possible toconfigure this workstation as a mobile station, e.g. as a mobileterminal (PDA, mobile handset). This mobility would generate evenfurther advantages for an end user.

The diagram in FIG. 3 shows the central position of the frameworkprogram coupling the software applications. In order to implement thesystem or method according to the invention, it is natural to choose aclient/server architecture. In this respect, the framework program (IF;FIG. 2) can be implemented on a single server or on several arbitraryservers which can be distributed in an IT environment. FIG. 3 shows thatthe framework program (IF; FIG. 2) is located on a server IFS(Industrial Framework Server). The clients are attached to this centralserver IFS, being connected by the bi-directional information pathwaysI2-I8. The clients include firstly the applications from the ERP, MESand automation levels. These applications are shown at the lower edge ofthe diagram in FIG. 3. These applications are connected to the frameworkprogram (IF; FIG. 2) and therefore the server IFS via the adaptersAD4-AD6. The adapters AD4-AD6 are connected to the applications via APIinterfaces API1-API3 (API stands for Application ProgrammableInterface). An Application Programmable Interface represents aninterface with a set of commands. APIs are also used in the conversionof lists of parameters from one format to another format and in theinterpretation of the arguments in one or both directions. The APIs are,as it were, the glue between the applications and the adapters. Theconnection between the adapters AD4-AD6 and the framework program (IF;FIG. 2) (shown in FIG. 3 by means of the bi-directional informationpathways I3-I5) takes place via suitable data formats (e.g. XML),suitable protocols (XOP, OPC, etc.) and suitable transport mechanisms(e.g. DCOM or MSMQ). HTTP (Hyper Text Transfer Protocol) can also beused in this respect. The protocol SOAP (Simple Object Access Protocol),based on XML (extensible Markup Language), can also be used forintegrating the adapters AD4-AD6 into the framework program (IF; FIG. 2)or the associated server IFS. Clients or applications which supportActiveX documents or calls can be integrated particularly advantageouslyinto the framework program (IF; FIG. 2) or the server IFS. Alongsideadapters, the applications can also be linked to the framework programby means of wrappers or other integration mechanisms.

The repository IFR (Industrial Framework Repository) can be connected tothe server IFS as a further client. The connection is shown by means ofthe bi-directional information pathway I2 in FIG. 3. The repository IFRis used in order to hold data in a secure and persistent manner. Thisdata can be accessed via method calls. Objects, methods and runtime dataare stored in the repository, among other things.

Further clients of the server IFS are shown in the upper half of thediagram. The Personalized Industrial Workplace PIW2 and any engineeringenvironment EU present are clients of the server IFS. The PersonalizedIndustrial Workplace PIW2 is connected to the framework program (IF;FIG. 2) or the server by means of the bi-directional information pathwayI6, and the engineering environment EU correspondingly by means of thebi-directional information pathway I7. The three dots show that furtherclients can be attached to the server IFS. The fact that, moreover, afurther client C, being connected by means of the information pathwayI8, is attached to the server IFS is indicated in FIG. 3.

The connection of the clients IFR, PIW2, EU and C takes placecorrespondingly via APIs or via customary data formats (e.g. XML),customary protocols (XOP, OPC, etc.) and customary transport mechanisms(e.g. DCOM, HTTP or MSMQ).

The adapters AD4-AD6 that are employed enable access to data and alsomethods of the individual applications which they connect to theframework program (IF; FIG. 2) These adapters are very flexible and notdefined on the basis of individual specific protocols or specifictransport mechanisms. If the adapters are employed in a runtimeenvironment, they are configured in such a way as to ensure that certainnecessary data from an application is available in the serverenvironment at the right time. As already noted, this can be effectedvia different protocols and transport mechanisms. Several adapters,which can also possess minor server properties (such as the execution ofworkflows, the provision of various communication options, etc.) can belocated in a runtime environment. These adapters can run on therespective application computer. However, they do not need to run ononly one machine; they can also be distributed.

Software applications, particularly MES (Manufacturing ExecutionSystems) applications, are often present in heterogeneous form; forexample, they can possess different data formats or object models or beimplemented in different programming languages. The system or methodaccording to the invention makes it possible to integrate heterogeneousapplications of this type with the aid of a framework program.Communication between these applications is effected on the basis ofmeans of communication such as HTTP, DCOM, MSMQ, etc. However, thecommunication, i.e. the exchange of data, between the applications isindependent of these means of communication, i.e. the applications canignore the application means.

The diagram in FIG. 4 shows the object structure of a “component” as ameta object model of the framework program (IF; FIG. 2) in UML (UnifiedModeling Language). In the system and method according to the invention,the software applications to be integrated and the underlying means ofcommunication (e.g. HTTP, MSMQ, etc.) are mapped to an object model ofthe framework program (IF; FIG. 2). As a result, intrinsicallyheterogeneous applications possess a common object model. As a result,all the methods, data structures, objects, etc. of the foreignapplications to be integrated are shown in a common object model. Thisobject model is very generic and represents a meta object model. Thecore of this object model consists of an object type named “component”.A component can in turn aggregate other components and/or containspecific types of components, referred to as variables, to which certainvalues are assigned in operation. Components and variables can alsopossess additional attributes in each case.

This object model forms the basis of the adaptation of MES applicationsor other applications. This means that the structures of theapplications are translated or mapped to structures of this objectmodel. All the applications to be integrated are represented in thediagram of this object model within the framework program (IF; FIG. 2).The underlying means of communication are also mapped to this genericobject model. All applications and all underlying means of communicationare then represented in a uniform and homogeneous object model in theframework program (IF; FIG. 2). As a result, communication links can beset up between the applications very simply and easily.

In the diagram in FIG. 4, the generic component “component”, whichrepresents the core of the object model, is presented in UML notation.

The square boxes represent parts of the object model. A lozenge linkrepresents an aggregation (an ‘is part of ’ link); a triangle representsinheritance (an ‘is a ’ link). The diagram in FIG. 4 therefore showsthat a component can consist of several components and furthermore, acomponent can be part of another component. A component is connected toattributes and variables by means of a lozenge link. In other words, acomponent can incorporate attributes and variables. Attributes aredescriptive data. All the objects in a class possess the same attributesbut generally different attribute values. An attribute value is a valueallocated to an attribute from its value range. A variable can assumevalues of certain data types (e.g. integer, real, etc.). As isrepresented by the lozenge link, a component can contain severalvariables. However, a component can also be a superordinate class of avariable as is represented by the triangle link. In other words, avariable can be a derived component. The lozenge and triangle links canalso incorporate cardinalities.

The software applications to be integrated and the underlying means ofcommunication are mapped to this generic object structure, i.e.“component” structure, of the framework program (IF; FIG. 2) by means ofmapping mechanisms such as adapters or wrappers.

The diagram in FIG. 5 shows how the MES application WinCC (WinCC is thename of a process monitoring system produced by Siemens) is mapped tothe “component” structure as shown in FIG. 4. The arrow in the middle ofFIG. 5 shows that mapping, i.e. a conversion, is involved. Theabbreviation IF above this arrow indicates that the mapping involvesmapping into the object model of the Industrial Framework, i.e. theunderlying framework program (IF; FIG. 2).

The object model of WinCC consists of name spaces (NS stands for NameSpace) with what are referred to as “tags”. Tags are simple data objectswhose properties can be exchanged between server and clients. Theirproperties can be dynamic but also static. In an external application tobe integrated, tags can be present in a flat or hierarchical name space.Tags can moreover be furnished with access rights (readable, writable,readable/writable). In an adapter, a tag is a placeholder (proxy) for anobject of an external application to be integrated.

A distinction must be made in this respect to the effect that the term“tag” is used for markings in languages such as HTML and XML.

It is shown at the left-hand edge of FIG. 5 that the WinCC name space(NS) contains tag 1 and tag 2. Three dots show that it can also containfurther tags. This structure is mapped to the “component” structure ofthe meta object model, as shown at the right-hand edge of FIG. 5, bymeans of adapters, wrappers or other mechanisms. The name space NSbecomes the component NS which contains tag 1 and tag 2 as variables.Three dots show that the component NS can contain further elements. Thechosen notation is based on the collaboration diagrams known from UML.

The diagram in FIG. 6 shows how a SAP application is mapped to the“component” structure (meta object model of the framework program). FIG.6 also shows by means of the arrow placed in the middle that mapping orconversion is shown. The tabular IDOC structure of SAP applications isshown on the left-hand side of FIG. 6. In FIG. 6, the two entries S1 andS2 are represented in the table and furthermore an arrow from S1 to S2shows that a reference from entry S1 to entry S2 is present. The threedots express the idea that an IDOC table can contain further elements.An IDOC table is mapped to a component IDOC of the object model of theframework program (IF; FIG. 2). The entries in the table (SI, S2) aremapped to variables of the component IDOC in each case. The chosennotation is based on the collaboration diagrams known from UML.

The underlying communication mechanisms (HTTP, MSMQ, DCOM, etc.) arealso mapped to a “component” structure of this type in each case. Thismakes uniform and homogenous manipulation of the various means ofcommunication possible.

The diagram in FIG. 7 shows how a communication link is set up betweenMES applications. As already explained above, the applications and theunderlying communication mechanisms are mapped to a uniform “component”structure (meta object model of the framework program).

FIG. 7 shows how a communication connection is set up between the MESapplications MES′ and MES″. These MES applications MES′ and MES″ aremapped to the “component” structure of the framework program (IF; FIG.2) via adapters or wrappers. The underlying means of communication(HTTP, MSMQ, DCOM, etc.) are also mapped to the generic object model ofa “component” structure via adapters or wrappers. In the frameworkprogram (IF; FIG. 2), these means of communication are then representedby means of a component transport system (TS). This component transportsystem (TS) ignores the underlying means of communication. In setting upa communication link, therefore, it does not matter which is ultimatelythe underlying physical means of communication. The means ofcommunication are therefore essentially interchangeable.

The communication link between the MES applications MES′ and MES″ is setup by means of what is referred to as a “connection”. A connectionconnects any two objects of the object model. Since the connectionrefers to objects of the generic object model, it knows their semanticsand knows what special features must be set up in making the connection,i.e. method objects must be manipulated differently from pure dataobjects, for example. Furthermore, the connection is supported by atransport system. The transport system is also present as part of thegeneric object model of the framework program (IF; FIG. 2). A connectioncan be uni-directional or bi-directional.

Data flowcharts can be used for projecting the communication linkbetween applications, by connecting the nodes by means of correspondingdata flows.

The diagram in FIG. 8 shows the object structure of a “connection” inUML notation. A connection is a generic object which consistsfundamentally of two parts: firstly the wrappers of the specific meansof communication and secondly a collection of properties, i.e.characteristics which can be set via this means of communication. Theseproperties and the connection itself are in turn “components” of theobject model, with the properties being given simply by means of a listof variables. A transport wrapper in turn also contains properties, i.e.characteristics. If MSMQ is used as the means of communication, the nameof the message queue used is a property of this type, for example. Thecardinality (1:2) indicates that the connection in FIG. 8 incorporatesat least one but no more than two transport wrappers. The otheraggregation links (lozenge symbol), as shown in FIG. 8, can alsoincorporate cardinalities. A transport wrapper can also incorporatemethods, such as a method for opening a specific transport channel, amethod for closing a specific transport channel, a method for sending astring, a method for receiving a string, etc.

Means of communication are usually mapped to the object model of theframework program by means of wrappers, but it is also possible inprinciple to integrate means of communication in the framework programby means of adapters.

The diagram in FIG. 9 shows the schematic structure of an adapter. Eachadapter is a specific component with the special property that thecomponent of an adapter runs in a dedicated process in each case. Eachadapter already brings a certain default structure with it, which againis represented as a tree structure of objects of the framework program,i.e. components and variables, and which makes certain points availableat which the adapter can deliver certain information to the outside.Examples of this comprise status information about the status of theadapter (is the adapter connected to its application, is the applicationrunning, version information, etc.). Furthermore, an adapter can alsodeliver information about the external system, i.e. the externalapplication, to the outside. An adapter can deliver structures to theoutside which other adapters or other applications can access by meansof the “Object Space”. An adapter can also deliver information withrespect to a communication infrastructure to the outside. ‘Communicationinfrastructure’ means objects for sending, receiving and convertingmessages but also mechanisms for performing routing and mechanisms forlogging the exchange of data in the adapter. Furthermore, thecommunication infrastructure of an adapter includes what are referred toas inports and outports which physically receive or send the messages.An adapter is present as a dedicated process of the operating system,i.e. if an adapter crashes, it has no impact on other adapters. Anadapter is therefore a dedicated enclosed application which can beexecuted on its own.

Adapters and wrappers are mechanisms for integrating software componentsinto a software system. A wrapper maps the API (Application ProgrammableInterface) of a foreign component or an application to be integratedinto the object model of the software system, in this case the frameworkprogram (IF; FIG. 2). Thus, for example, a method of the API of theapplication to be integrated becomes a method of the framework programor an integer data type of the API of the application to be integratedbecomes an integer data type of the framework program, etc. A wrappertherefore brings the API of the application to be integrated into thelanguage, into the nomenclature and into the object world of theframework program.

An adapter, on the other hand, is one level of abstraction higher than awrapper. Adapters represent a standardized view of applications to beintegrated and the framework program into which the application to beintegrated is inserted can ignore that application. An adapter makesfunctionality available to start up, operate and handle the system to beintegrated, i.e. the application to be integrated. With the aid ofadapters, for example, a user can use a SAP application without being aSAP expert. SAP applications are mapped into the object model of theframework program by means of the IDOC adapters (see FIG. 6) and arethen used as objects of the framework program (component IDOC).

Two applications (e.g. MES applications) can be brought together on apeer-to-peer basis by means of the system and method according to theinvention without a connection of this type having to be programmed on apeer-to-peer basis in each case. These connections are projectedaccording to the invention by establishing a connection (see FIG. 7).

The diagram in FIG. 10 shows a projection user interface for setting upa communication connection between applications. The display device AZ(e.g. a monitor or a display) possesses one or more menu lists ML. Themenu lists ML contain function buttons which can be activated by theuser by way of a mouse click, for example. Self-defined function buttonscan also be stored in the menu lists ML by the user. Operation oractivation of the projection interface can also be effected via otherinput tools (e.g. keyboard, light pen or the like). In FIG. 10, theprojection user interface is divided into the screen areas BB1-BB3. Itis also conceivable, however, that further or only one or two screenareas are present.

The object structures OB1 and OB2 of the applications between which acommunication link is to be set up are shown in the screen areas BB1 andBB2. However it is also conceivable, that only the structure of therespective adapters is shown in the screen areas BB1 and/or BB2. A usercan now connect elements of the two object structures OB1 and OB2 toeach other via drag & drop mechanisms. If a user sets up a communicationlink of this type, information with respect to this connection or theconnections is shown in a screen area BB3. Information of this type canrefer to the name, value or type of the connection set up. It is alsoconceivable that further information is shown with respect to aconnection. By means of the mechanism described in FIG. 10, it ispossible for a user to project communication links between twoapplications. Communication links between two applications therefore nolonger need to be programmed individually. Efficiency in the creation ofsoftware solutions for MES systems rises enormously as a result andSystem Integrators and System Developers in particular can increasetheir efficiency.

Applications to be connected, particularly MES applications, but alsothe communication mechanisms, are mapped into the object model of theframework program (Industrial Framework) by using wrappers and/oradapters and, as a result, can be manipulated in a uniform homogenousmanner in the framework program (Industrial Framework). The invention isadvantageous in that the very heterogeneous structures of theapplications are mapped onto a common model and can be used veryconveniently and easily by a user by means of generic mechanisms (ObjectComponent as meta object model). That is to say that the effort ofprogramming is eliminated and, as a result, this communication can beprojected by establishing what is referred to as a connection.

The system or method according to the invention described above can beimplemented as a computer program in languages known for the purpose. Acomputer program implemented in this way can be stored and transportedvia electronic data pathways, but also on data carriers, in a similarlyknown manner.

1.-13. (cancelled)
 14. A system for communicating between softwareapplications, comprising: at least one mechanism of communication; atleast one central processing unit for storing the software applications;and at least one framework program coupling the software applications,wherein the software applications are mapped to an object model of theframework program, wherein the mechanism of communication is mapped tothe object model of the framework program, wherein a communication linkis set up between two or more objects of the object model by connectingmethods of the objects and/or data of the objects and/or the objectsthemselves, wherein an exchange of data and/or information and/or eventstakes place over the communication link, wherein any desired data and/orinformation and/or events of the software applications being exchangedover the communication link independently of the internal format of therespective software applications and/or independently of the underlyingformat of the mechanism of communication.
 15. A system as claimed inclaim 14, wherein the communication link is transparent for a userand/or other systems with respect to the underlying mechanism ofcommunication.
 16. A system as claimed in claim 14, wherein the mappingto the object model is effected by a adapter and/or by wrapping.
 17. Asystem as claimed in claim 15, wherein the mapping to the object modelis effected by a adapter and/or by wrapping.
 18. A system as claimed inclaim 14, wherein the communication link is set up with a display devicehaving input tools and/or via an autonomously operating program.
 19. Asystem as claimed in claim 15, wherein the communication link is set upwith a display device having input tools and/or via an autonomouslyoperating program.
 20. A system as claimed in claim 16, wherein thecommunication link is set up with a display device having input toolsand/or via an autonomously operating program.
 21. A system as claimed inclaim 14, wherein the communication link is set up between two or moreobjects by connecting the objects, which are shown in different screenareas of the display device, by a drag & drop operation with the aid ofthe input tools.
 22. A system as claimed in claim 14, wherein thesoftware applications are MES applications.
 23. A method forcommunicating between software applications, comprising: providing atleast one mechanism of communication; providing at least one frameworkprogram coupling the software applications; storing the softwareapplications on at least one central processing unit; mapping thesoftware applications to an object model of the framework program;mapping the mechanism of communication to the object model of theframework program; setting up a communication link between two or moreobjects of the object model by connecting methods of the objects and/ordata of the objects and/or the objects themselves; and providing anexchange of data and/or information and/or events via the communicationlink, wherein any desired data and/or information and/or events of thesoftware applications are exchanged via the communication linkindependently of the internal format of the respective softwareapplications and/or independently of the underlying format of themechanism of communication.
 24. A method according claim 23, wherein thesoftware applications are MES applications.
 25. A method according claim23, wherein the communication link is transparent for a user and/orother systems with respect to the underlying mechanism of communication.26. A method according claim 23, wherein the mapping to the object modelis effected by an adapter and/or by wrapping.
 27. A method accordingclaim 25, wherein the mapping to the object model is effected by anadapter and/or by wrapping.
 28. A method according claim 23, wherein thecommunication link is set up with a display device by input tools and/orvia an autonomously operating program.
 29. A method according claim 25,wherein the communication link is set up with a display device by inputtools and/or via an autonomously operating program.
 30. A methodaccording claim 23, wherein the communication link is set up between twoor more objects by connecting the objects, which are shown in differentscreen areas of the display device, by a drag & drop operation with theaid of the input tools.
 31. A method according claim 23, wherein themethod is implemented by a computer program.
 32. A data carrier,comprising a computer program, the computer program is implementing amethod for communicating between software applications, the methodcomprising: providing at least one mechanism of communication; providingat least one framework program coupling the software applications;storing the software applications on at least one central processingunit; mapping the software applications to an object model of theframework program; mapping the mechanism of communication to the objectmodel of the framework program; setting up a communication link betweentwo or more objects of the object model by connecting methods of theobjects and/or data of the objects and/or the objects themselves; andproviding an exchange of data and/or information and/or events via thecommunication link, wherein any desired data and/or information and/orevents of the software applications are exchanged via the communicationlink independently of the internal format of the respective softwareapplications and/or independently of the underlying format of themechanism of communication.
 33. A data processing apparatus comprising acomputer program to perform a method for communicating between softwareapplications, the method comprising: providing at least one mechanism ofcommunication; providing at least one framework program coupling thesoftware applications; storing the software applications on at least onecentral processing unit; mapping the software applications to an objectmodel of the framework program; mapping the mechanism of communicationto the object model of the framework program; setting up a communicationlink between two or more objects of the object model by connectingmethods of the objects and/or data of the objects and/or the objectsthemselves; and providing an exchange of data and/or information and/orevents via the communication link, wherein any desired data and/orinformation and/or events of the software applications are exchanged viathe communication link independently of the internal format of therespective software applications and/or independently of the underlyingformat of the mechanism of communication.